1. Field of the Invention
The invention relates generally to graphical display of data and in particular to displaying a graph view of multiply connected objects.
2. Background Information
Visualization and interaction with data helps users quickly understand the types of data available and their interrelationships. Often, sets of data are presented as lists, or tables with columns, depicting specific attributes of each instance of data. Analyzing and understanding the nature and state of units of data, and appreciating any subtle relationships and connections therebetween, can be difficult and time consuming. For example, in a screen display, large sets of textual data cannot fit on a single display without the user having to scroll or page, whereby a user cannot retain a view of all the data at once. A conventional solution is to draw a graph of objects with lines indicating relationships between pairs of objects, and some arbitrary shape representing each instance of an object. Typically, the scale of the graph can be controlled, and the data arranged in such a way that all data or a selection of data can be viewed in a single screen. An example of this is a unified modeling language (UML) editor, which allows users to examine a set of object classes and the relationships between them. The user can move around the graph, zoom into items of interest and view details of specific classes (e.g., zoom into objects in the graph and detect relationships that exist between classes).
Drawing graphs requires the ability to analyze the relationships between data objects and calculate the coordinates of each data object in a display that is easy to comprehend. Various solutions exist to draw datasets as graphs: rich applications that use the native drawing capabilities of the underlying operating system, or client-server applications where the server processes the graph data and produces a static bitmap image which the user can view. The problem with rich client applications as a means to deliver data visualization to users is that each user must install such an application on the user machine, and the data may need to be stored and processed locally on that machine. Any changes to the application require the user to continually change and upgrade the installed application, and the users are limited to the capabilities of that dedicated rich client application. Such vendor buy-in locks users to a specific style of displaying data.
An alternative approach involves a server application that processes the data, calculates the layout of the data and renders a bitmap image of the graph, for example in GIF or JPG format. Client devices, such as web browsers, can then read the image from the server machine over a network and display to users. Users can access the data from anywhere on a distributed network and do not need to install or maintain any software. However, the image is static. It cannot be scaled, transformed, or changed, without losing visual clarity and the user having to request that the server application reprocess the entire data set and produce a new bitmap. Sending a bitmap image that is large enough to fill a display screen over a network connection is inefficient because bitmaps can only be compressed up to a limit. For maximum clarity, the bitmap is not compressed at all, whereby such images comprise megabytes of data. Multiplied over several users making several requests, this approach does not scale well.
An approach for drawing object graphs in a browser client is to use Cascading Style Sheets (CSS) to display HTML elements as boxes, connected by lines. Arrowheads are simulated by using a scheme with beveled outline styles. The entire graph can be represented by normal HTML elements, and with a suitable style sheet applied, the elements can appear as a visual graph. This is efficient in terms of storage and memory requirements, portable across different browsers, and is accessible by screen readers, due to the textual nature of the data definitions. This is suitable for simple graphs, but it would not easily apply to more densely populated object graphs where multiple intersecting connections occur between objects. It would also not easily lend itself to scaling and graphical transformations. There are also some browser differences in CSS compliance that need to be considered.
Vector graphics technology is the most efficient way of rendering data as a graph, because only the coordinates of shapes and how those shapes are connected need to be stored or sent over networks. Web browser clients are lightweight applications with an advantage of services and applications that do not need to be installed and maintained; they just display what is available from a server-based application. Web browsers can display textual data and bitmap data as described previously, but in order to render vector graphics, applications would need to embed or rely on pre-installed plug-ins or components, such as ActiveX controls, Macromedia Flash or Java applets. These are proprietary applications, do not typically work consistently across all browser types, and development of content for them requires specific, proprietary development environments. Most common browsers offer JavaScript scripting capabilities that can directly manipulate the document object model (DOM) of the rendered page, but this does not include control of vector graphics. Browsers also provide the ability to make asynchronous calls to a server, such that data can be retrieved in a separate process and only selected content updated on the page. This data is typically sent in XML or some other text format.
Another known problem with navigating graphs is the location of objects relative to other objects in the graph. This is especially the case when the user has zoomed in to view a few objects in detail, but as a result they cannot see surrounding objects in the graph. Scrolling around the current position may cause the user to be disoriented.
As a user interacts with a graph (changing filter settings, or redraws the graph from a different origin object), the user may desire to return to a previously rendered graph. This is not straightforward in an asynchronous browser environment. One solution is to store the rendered graph on the server but this requires storage per graph per user, which can quickly mount up.